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Cloudflare Magic Transit 
bietet Netzwerkschutz und 
Performance-Steigerung 


Cloudflare Magic Transit bietet Schutz vor DDoS-Angriffen und eine 
Beschleunigung des Traffic für lokale, cloudbasierte und hybride 
Netzwerke. Mit Rechenzentren in 200 Städten und einer DDoS- 
Minderungskapazität von mehr als 42 Tbit/s kann Magic Transit 

Angriffe in der Nähe ihres Ursprungs innerhalb von 10 Sekunden (und 
durchschnittlich weniger als 3 Sekunden) erkennen und eindämmen — und 
das alles mit integrierten Leistungsvorteilen. 


In diesem Whitepaper stellen wir die Ergebnisse von Catchpoint-Tests 

vor, die wir über unser Netzwerk durchgeführt haben, um zu quantifizieren, 
welche Auswirkungen Magic Transit auf die Latenz hat. Diese 
Testergebnisse zeigen, dass sich die Netzwerk-Performance (Latenz und 
Paketverlust) für den Testkunden verbesserte, wenn der Datenverkehr 

über Cloudflare Magic Transit geroutet wurde. Insbesondere stellten wir in 
unseren Testergebnissen fest, dass die Latenz um 3 ms abnahm und der 
Paketverlust nahezu Null war, wenn der Datenverkehr über Magic Transit 
geroutet wurde. 


+49 89 2555 2276 | enterprise@cloudflare.com | www.cloudflare.com/de-de/ 


Wie schützt Magic Transit die Netzwerkinfrastruktur, ohne die Netzwerk- 
Performance zu beeinträchtigen? 


Vor Magic Transit gab es zwei primäre Strategien zum Schutz der Netzwerkinfrastruktur vor DDoS-Angriffen: lokale 
Hardware-DDoS-Geräte und Cloudbasierte Scrubbing-Lösungen. 


Lokale Hardware-Geräte leisten gute Arbeit beim Schutz Ihrer Infrastruktur - bis zu einem gewissen Grad. Diese Boxen 
haben limitierte Bandbreite und sie können durch größere oder gleichzeitige Angriffe überwältigt werden. Die Hardware 
erfordert auch eine große Vorabinvestition und hohen Ressourcenaufwand für Verwaltung und Wartung. 


Cloudbasierte Scrubbing-Center sind als einfachere Alternative entstanden: Routen Sie Ihren Datenverkehr durch 
deren Scrubbing-Center, wo der Angriffsverkehr herausgefiltert wird. Dadurch wurden die hohen Kosten und 
Wartungsprobleme mit lokalen Boxen eliminiert. 


Dadurch ergab sich allerdings ein neues Problem: signifikante Latenz. 


Da diese Cloud-Provider über eine begrenzte und geografisch disparate Anzahl von Scrubbing-Centern verfügen, 
bedeutet dies, dass Datenverkehr unter Umständen einen langen Weg ins Scrubbing-Center zurücklegen muss, 
bevor es seinen eigentlichen Bestimmungsort erreicht. Cloud-Provider verfügen in der Regel nur über eine Handvoll 
Scrubbing-Center, und wenn Sie oder Ihre Endbenutzer sich nicht in der Nähe eines dieser Zentren befinden, 

muss Ihr Datenverkehr eine weite Strecke zurücklegen, selbst wenn das Endziel in der Nähe liegt. Dabei spricht 

man vom sogenannten Posauneneffekt, der oft zu spürbaren und schmerzhaften Verzögerungen führt. (Er wird als 
"Posauneneffekt" bezeichnet, weil sich bei der Visualisierung des langen Hin- und Rückwegs des Datenverkehrs auf 
einer Karte eine Posaunen-ähnliche Darstellung ergibt). 


Es gibt nur wenige und weit entfernte 'Scrubbing Center’, die sich der DDoS-Minderung widmen. Daher muss der Netzwerk-Traffic 
für jede zusätzliche L4-7-Verarbeitung, die zusätzliche Verzögerungen verursacht, zu einem alternativen Rechenzentrum geleitet werden. 
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Betrachten Sie das obige Szenario, bei dem Ihr Datenverkehr auf den Ebenen 3-4 sowie für Ebene 7-Dienste (wie WAF, 
Bot Management usw.) verarbeitet werden muss. In diesem Fall trifft Ihr Datenverkehr zunächst auf ein entferntes 
L3-Scrubbing-Center zur L3-DDoS-Minderung und wird dann zur weiteren L7-Verarbeitung an ein sekundäres 
Rechenzentrum weitergeleitet, wodurch dem End-to-End-Traffic ein Netzwerk-Hop hinzugefügt wird; dies führt 

zu unnötiger Latenz. Die Latenzzeit ist besonders ausgeprägt, wenn der Cloud-Provider über eine begrenzte Anzahl von 
Scrubbing-Centern verfügt und die Quelle Ihres Netzwerk-Traffic weit davon entfernt ist. 


Magic Transit bietet eine bessere Lösung. Anstelle von dedizierten Scrubbing-Centern lassen wir jedes Rechenzentrum 
im globalen Netzwerk von Cloudflare das Scrubbing übernehmen. Tatsächlich wird in jedem Cloudflare-Rechenzentrum 
das gesamte Spektrum aller Cloudflare-Dienste ausgeführt. Das bedeutet, dass Ihr Datenverkehr nur zum 
nächstgelegenen Cloudflare-Rechenzentrum geleitet werden muss; mit Rechenzentren in über 200 Städten in mehr als 
100 Ländern ist der Weg dorthin wahrscheinlich kurz. 


In jedem Cloudflare-Rechenzentrum wird das gesamte Spektrum an L3-L7-Diensten ausgeführt, 
so dass der Netzwerk-Traffic am gleichen Standort verarbeitet wird. 
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Dies bedeutet keinen Posauneneffekt und eine sehr geringe Latenzzeit. Bei der Entwicklung von Magic Transit stand 
die Netzwerk-Performance an erster Stelle; wir wollten sicher sein, dass unsere Benutzer die Performance nicht um der 
Sicherheit willen opfern müssen. 


Catchpoint-Tests 


Um dies zu verifizieren, haben wir mit Catchpoint einige Tests durchgeführt, um die Auswirkungen der Verwendung 
von Magic Transit auf die Netzwerk-Performance zu untersuchen. Mit einer globalen Verteilung von Proben führten wir 
ICMP-Ping-Tests an einer IP-Adresse hinter Magic Transit und einer weiteren hinter Magic Transit durch, die beide auf 
derselben Netzwerkinfrastruktur gehostet werden. Dadurch konnten wir Latenz, Paketverlust und Jitter gleichzeitig 
messen, um den Unterschied in der Performance zu erkennen. 


Latenz (Ping hin und zurück) Leistung (ms) mit Magic Transit (blau) und ohne Magic Transit (grün) 
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Jitter-Performance (ms) mit Magic Transit (blau) und ohne Magic Transit (grün) 
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Paketverlust-Performance (in Prozent) mit Magic Transit (blau) und ohne Magic Transit (grün) 
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In dem oben dargestellten Test stellt die blaue Linie die Performance mit Magic Transit dar, während die grüne Linie die 
gleiche Performance ohne Magic Transit zeigt. 


Testergebnisse: 


Performance Mit Magic Transit (blau) Ohne Magic Transit (grün) 
Latenz 28,96 ms 31,98 ms 

Jitter 15,61 ms 15,24 ms 

Paketverlust 0,52% 5,26% 


Wichtigste Erkenntnisse aus diesen Tests: 


e Latenz hat sich bei der Verwendung von Magic Transit um 3 ms verringert 
e Jitter hat sich bei Verwendung von Magic Transit um 0,36 ms erhöht 


e Paketverlust war fast null (bei 0,52%) bei Verwendung von Magic Transit im Vergleich zu 5,26% Paketverlust ohne 
Magic Transit 


Was bedeuten diese Ergebnisse? 


Latenz: Latenz ist die Zeitdauer, die Datenpakete benötigen, um von einem Punkt zu einem anderen Punkt im 
Netzwerk zu gelangen. In unserem Test haben wir über das Cloudflare-Netzwerk eine geringere Latenz gemessen. 


Cloudflare optimiert die Traffic-Routen laufend entsprechend dem Zustand der verschiedenen Netzwerkpfade, so dass 
die ausgehenden Pfade, die Pakete von Cloudflare zum Kundennetzwerk nehmen, oft effizienter sind als jener, den diese 
Pakete ohne die Optimierung durch Cloudflare nehmen würden. 


Dadurch wird sichergestellt, dass die Netzwerklatenz nicht erhöht wird und in vielen Fällen—wie in unseren Ergebnissen 
ersichtlich-verringerte sich diese sogar. Dies ist besonders wichtig für latenzempfindliche (Echtzeit-)Anwendungen wie 
Online-Spiele und Voice-over-IP (VoIP). 


Jitter: Netzwerk-Jitter ist der Betrag der Verzögerung zwischen der Paketzustellung über ein Netzwerk. Jitter niedrig 
zu halten ist besonders wichtig für Anwendungen wie VoIP. Mit Magic Transit wurde der Jitter um 0,36 ms erhöht. Dies 
wird selbst für jitterempfindliche Anwendungen als vernachlässigbar gering angesehen. 


Paketverlust: Paketverlust tritt auf, wenn eines oder mehrere der Pakete in einer Netzwerkübertragung 

ihren Bestimmungsort nicht erreichen. Je nach Protokoll kann der Paketverlust dazu führen, dass mehr Zeit für die 
erneute Übertragung benötigt wird oder die Qualität sich verschlechtert. Bei extrem zeitempfindlichen Übertragungen 
wie Videokonferenzen gilt ein Paketverlust von weniger als 1% als akzeptabel*. In unseren Tests haben wir festgestellt, 
dass der Paketverlust über das Netzwerk von Cloudflare fast auf Null zurückgegangen ist (im Vergleich zu über 5% 
Paketverlust ohne Magic Transit) 


Zusammenfassend lässt sich sagen, dass die Auswirkungen von Magic Transit auf Latenz, Jitter und Paketverlust die 
Benutzererfahrung nicht beeinträchtigen und in vielen Fällen sogar verbessern können. Mit anderen Worten: Cloudflare- 
Kunden müssen bei der Verwendung von Magic Transit keine Abstriche bei der Netzwerk-Performance machen. 


Darüber hinaus lässt sich Cloudflare Magic Transit mit dem gesamten Spektrum an Cloudflare-Produkten für 
Sicherheit, Performance und Zuverlässigkeit integrieren, um die Performance von Websites und Webapplikationen noch 
weiter zu optimieren. 


Für weitere Informationen über Cloudflare Magic Transit, besuchen Sie www.cloudflare.com/magic-transit 
oder kontaktieren Sie uns unter: sales@cloudflare.com 


*https://web.archive.org/web/20131010010244/http://sdu.ictp.it/pinger/pinger.html 
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